Skip to content

UN-2265 [FEAT] Show the running platform version on the profile page#2034

Open
athul-rs wants to merge 4 commits into
mainfrom
UN-2265-frontend-version-display
Open

UN-2265 [FEAT] Show the running platform version on the profile page#2034
athul-rs wants to merge 4 commits into
mainfrom
UN-2265-frontend-version-display

Conversation

@athul-rs

@athul-rs athul-rs commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

What

  • The profile page's Organization card now shows a Platform Version field (e.g. v0.144.0) on all deployment targets — OSS docker, cloud, on-prem.

Why

UN-2265 — most apps surface their running version; users reporting issues currently have no way to tell us what version they're on, which slows down troubleshooting.

How

The version is supplied at runtime (never baked into the image) and flows env → runtime config → UI with no new endpoints:

  1. UNSTRACT_APPS_VERSION is provided by the deployment:
    • OSS docker-compose (docker/docker-compose.yaml): UNSTRACT_APPS_VERSION=${VERSION} on the frontend service — the same ${VERSION} that already tags every image, so the shown version always matches what's running.
    • Enterprise / On-prem (Helm): injected from the chart version anchor — see companion PR Zipstack/unstract-cloud#1621.
  2. generate-runtime-config.sh: reads UNSTRACT_APPS_VERSION (js-escaped) and injects version into window.RUNTIME_CONFIG at container start (existing mechanism).
  3. config.js: exposes config.version (runtime config first, VITE_VERSION env fallback for dev).
  4. Profile.jsx: renders the field only when a version is available, using the existing field-group styling.

Why runtime env and not a build-time bake (revised after review): RC→stable promotion only re-tags images — it does not rebuild them — so a version baked into the image at build time would freeze at the rc tag and be shown in Production. Sourcing from the runtime env (compose for OSS, Helm anchor for Enterprise) keeps the displayed version aligned with the promoted release. (per @ritwik-g / @ejhari)

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

  • No. Additive only: one extra key in the frontend runtime config and a conditionally rendered field. When UNSTRACT_APPS_VERSION is unset (older images, local dev server, or a deployment that doesn't set it), config.version is empty and the field simply doesn't render. No image now bakes a version, so nothing is removed that anything else depended on.

Database Migrations

  • None

Env Config

  • UNSTRACT_APPS_VERSION (frontend container) — supplied at runtime: docker-compose passes ${VERSION} in OSS; Helm injects the chart version anchor in Enterprise/On-prem (Zipstack/unstract-cloud#1621). No longer a build arg.

Relevant Docs

  • N/A

Related Issues or PRs

  • Companion (required pair for cloud/on-prem): Zipstack/unstract-cloud#1621 — injects UNSTRACT_APPS_VERSION into the frontend container from the Helm chart.
  • Jira: UN-2265

Notes on Testing

  • Biome lint clean; vite build succeeds; sh -n passes on the runtime-config script.
  • OSS: VERSION=v9.9.9 docker compose config renders UNSTRACT_APPS_VERSION: v9.9.9 on the frontend service; unset VERSION → empty → field hidden.
  • Manual: UNSTRACT_APPS_VERSION=v1.2.3 on the frontend container → profile page shows Platform Version: v1.2.3; unset → field hidden.

Screenshots

N/A

Checklist

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

Bake the build VERSION into the frontend image as
UNSTRACT_APPS_VERSION (same pattern as backend.Dockerfile), surface it
through the runtime config injected at container start, and show it as
a 'Platform Version' field on the profile page. Production CI already
passes *.args.VERSION to all images via docker bake, so published
images carry the real version on every deployment target; the field is
hidden when no version is available (e.g. local npm start).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 381a664a-3b28-4436-bc43-407163fea248

📥 Commits

Reviewing files that changed from the base of the PR and between 572d380 and fd66010.

📒 Files selected for processing (2)
  • docker/docker-compose.yaml
  • frontend/generate-runtime-config.sh
🚧 Files skipped from review as they are similar to previous changes (2)
  • docker/docker-compose.yaml
  • frontend/generate-runtime-config.sh

Summary by CodeRabbit

  • New Features

    • Added platform version information to the Organization section of the profile page when available.
    • Included version details in the app’s runtime configuration so the UI can display the current release version.
  • Bug Fixes

    • Improved handling of runtime config values to better support special characters in generated settings.

Walkthrough

Adds a version value from Docker Compose into runtime config, exposes it through frontend config, and shows it in the profile UI when present.

Changes

Platform version exposure

Layer / File(s) Summary
Compose and runtime config
docker/docker-compose.yaml, frontend/generate-runtime-config.sh
UNSTRACT_APPS_VERSION is wired from ${VERSION}, then escaped and written as version in window.RUNTIME_CONFIG.
Frontend config and profile UI
frontend/src/config.js, frontend/src/components/profile/Profile.jsx
config.js adds a version field with a runtime/env fallback, and Profile.jsx conditionally displays “Platform Version” when it exists.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the main change: showing the running platform version on the profile page.
Description check ✅ Passed The description follows the template and covers what, why, how, breaking changes, env config, testing, and related issues.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch UN-2265-frontend-version-display

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@greptile-apps

greptile-apps Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR adds a Platform Version field to the profile page's Organization card, sourced from the UNSTRACT_APPS_VERSION runtime environment variable rather than a build-time bake. The design specifically avoids embedding the version at image build time because RC→stable promotions only re-tag images (no rebuild), which would otherwise freeze the displayed value at the RC tag.

  • generate-runtime-config.sh gains a js_escape helper and writes version into window.RUNTIME_CONFIG at container start; when the env var is unset, the field is written as an empty string and correctly hides in the UI.
  • config.js exposes config.version (runtime config first, VITE_VERSION fallback for local dev), and Profile.jsx conditionally renders the field only when the value is truthy.

Confidence Score: 5/5

This is a purely additive change — one new runtime config key and one conditionally rendered UI field. When the env var is absent, the field simply does not appear.

All four changed files are straightforward and isolated. The escape helper correctly handles the characters that could break a JS string literal, the falsy guard in both config.js and Profile.jsx ensures the field is never rendered with an empty or undefined value, and the docker-compose change reuses the existing VERSION variable that already controls image tagging.

No files require special attention.

Important Files Changed

Filename Overview
docker/docker-compose.yaml Adds UNSTRACT_APPS_VERSION=${VERSION} to the frontend service environment; correctly inherits the same VERSION variable used to tag images.
frontend/generate-runtime-config.sh Adds js_escape helper and injects version into window.RUNTIME_CONFIG; correctly defaults to empty string so the UI field stays hidden when the env var is unset.
frontend/src/config.js Exposes config.version with runtime-config-first, VITE_VERSION-fallback priority; correctly falsy when neither source is set.
frontend/src/components/profile/Profile.jsx Conditionally renders Platform Version using existing field-group styling; only shown when config.version is truthy.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Compose as docker-compose / Helm
    participant Script as generate-runtime-config.sh
    participant Config as window.RUNTIME_CONFIG
    participant JSConfig as config.js
    participant UI as Profile.jsx

    Compose->>Script: "UNSTRACT_APPS_VERSION=v0.144.0 (at container start)"
    Script->>Script: js_escape(UNSTRACT_APPS_VERSION)
    Script->>Config: write version: "v0.144.0"
    Config->>JSConfig: runtimeConfig.version
    JSConfig->>UI: "config.version = "v0.144.0""
    UI->>UI: "{config.version && Platform Version field}"
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Compose as docker-compose / Helm
    participant Script as generate-runtime-config.sh
    participant Config as window.RUNTIME_CONFIG
    participant JSConfig as config.js
    participant UI as Profile.jsx

    Compose->>Script: "UNSTRACT_APPS_VERSION=v0.144.0 (at container start)"
    Script->>Script: js_escape(UNSTRACT_APPS_VERSION)
    Script->>Config: write version: "v0.144.0"
    Config->>JSConfig: runtimeConfig.version
    JSConfig->>UI: "config.version = "v0.144.0""
    UI->>UI: "{config.version && Platform Version field}"
Loading

Reviews (4): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile

Comment thread docker/dockerfiles/frontend.Dockerfile Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/generate-runtime-config.sh`:
- Line 13: The runtime-config write interpolates UNSTRACT_APPS_VERSION directly
into a JS string (version: "${UNSTRACT_APPS_VERSION:-}"), which can break the
resulting runtime-config.js if the env contains " or \; sanitize/escape the
value before writing. Replace occurrences of backslash and double-quote (and
newlines) in UNSTRACT_APPS_VERSION with escaped sequences (e.g. \ -> \\ and " ->
\") or produce a safe JS string using a JSON-stringifier (jq -R . or similar)
and then insert that quoted/escaped output into the version field so
runtime-config.js remains valid; update the portion of
generate-runtime-config.sh that emits the version line to use the
escaped/JSON-encoded value instead of the raw variable.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6d3b8725-fafd-4dd7-992a-783b76071583

📥 Commits

Reviewing files that changed from the base of the PR and between c14a3b3 and aeba845.

📒 Files selected for processing (4)
  • docker/dockerfiles/frontend.Dockerfile
  • frontend/generate-runtime-config.sh
  • frontend/src/components/profile/Profile.jsx
  • frontend/src/config.js

Comment thread frontend/generate-runtime-config.sh Outdated
Comment thread docker/dockerfiles/frontend.Dockerfile Outdated

# Capture build version at the very end so it doesn't affect layer caching
ARG VERSION=dev
ENV UNSTRACT_APPS_VERSION=${VERSION}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@athul-rs does this get set during cloud builds as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes — cloud frontend builds go through docker bake with *.args.VERSION=${{ inputs.tag }} (cloud-frontend-docker-build-push.yaml), same as OSS production-build.yaml, so cloud images get the rc tag baked in automatically. On-prem frontend builds use the same workflow pattern.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@athul-rs doesn't it mean we will show rc tags in the UI?

@ejhari ejhari Jun 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ritwik-g It is relatively ok to show rc tags in UI, as long as they appear internally only.

@athul-rs That being said, since we re-tag an existing rc tag to promote it to Production, the version input for frontend display has to come from the Helm chart dynamically, instead of being baked into the image. Is this the case now? Asking since an rc tag might get displayed instead in Cloud/On-prem Production as mentioned.

@jaseemjaskp jaseemjaskp left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@athul From my point of view, the platform version is not particularly relevant to display in OSS or other environments.

For OSS, users already know which version they have deployed locally. For on-prem deployments, we maintain a version tracker and customers know exactly which version they are running. In cloud deployments, customers are always on the latest version, and we already know what version is currently deployed.

Because of that, I don’t think customers need to be aware of the platform version. I also don’t recall many enterprise applications exposing the platform version prominently in the UI.

@chandrasekharan-zipstack

Copy link
Copy Markdown
Contributor

@jaseemjaskp I think its useful to display the version for several reasons and we don't lose anything on attempting to do so. Its more of a convenience here

  • becomes easier to debug issues across environments
  • anyone using our dev namespace easily infers the version and can refer that while sending messages
    • faced this concern first hand when I repeatedly kept deploying different versions for testing
  • OSS users also find this hard because they'll only do a ./run-platform.sh -u (for upgrade) and they'll not immediately know what version of Unstract is being used
  • I believe most applications do show the app version within the product itself, makes it easier to convey and reason about issues

Do you see any engineering challenges or concerns in displaying this?

…e config

- ARG VERSION defaults to empty so images built without a version hide
  the field instead of showing 'dev'
- Escape backslashes/quotes before embedding the version in the
  generated JS
@athul-rs

Copy link
Copy Markdown
Contributor Author

@jaseemjaskp fair point — taking this back to the ticket's intent rather than pushing my own view: UN-2265 was filed by @chandrasekharan-zipstack from a suggestion that surfacing the version helps support triage (when a user reports an issue, we can ask what version the UI shows instead of cross-referencing deploy trackers). The OSS docker-compose case is the strongest one IMO: latest images mean self-hosted users often genuinely don't know what they're running.

That said, this is a product call, not mine. Options as I see them:

  1. Merge as-is (field only shows where a version is baked, and it sits on the profile page rather than anywhere prominent).
  2. Gate it to OSS/on-prem only (trivial: don't pass the build-arg in cloud builds, the field auto-hides).
  3. Close the PR and mark UN-2265 as won't-do.

Happy with whichever you and Chandru align on — the change is additive and cheap to drop or gate.

@athul-rs

Copy link
Copy Markdown
Contributor Author

@hari-kuriakose What should be the approach here ? Let's update the PR and ticket in jira accordingly.

@ejhari

ejhari commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

@athul-rs We need to show the release version in UI, dynamically pulled from the Docker compose file in OSS and Helm chart in Enterprise.

Both OSS platform end users and Enterprise On-prem customer dev teams will not have a clue otherwise.

A release version is a vital information when filing or debugging an issue.

athul-rs and others added 2 commits June 29, 2026 21:47
RC->stable promotion re-tags images (it does not rebuild), so a version baked
into the frontend image at build time would stay frozen at the rc tag after
promotion. Drop the frontend.Dockerfile ARG/ENV baking and instead supply
UNSTRACT_APPS_VERSION from docker-compose using ${VERSION} -- the same value
that already tags the image, so the displayed version always matches what runs.

Addresses review from @ritwik-g / @ejhari (version must come dynamically from
compose in OSS and the Helm chart in Enterprise).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ion-display

# Conflicts:
#	frontend/generate-runtime-config.sh
@github-actions

Copy link
Copy Markdown
Contributor

Frontend Lint Report (Biome)

All checks passed! No linting or formatting issues found.

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants